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ABSTRACT 


A brief description of the history of the development of the Human 
Operator Simulator (HOS) model is presented. Features of the HOS micro- 
models that impact on the obtainment of visual performance data are discussed 
along with preliminary details on a HOS pilot model designed to predict the 
results of visual performance workload data obtained through oculometer 
studies on pilots in real and simulated approaches and landings. 


INTRODUCTION 


The HOS model has been under development for approximately 10 years. 

The concept behind the model was' formulated by Wherry (Ref. 1) in 1969. 
Analytics began the task for formalizing Wherry's ideas and converting them 
into a functioning model (Ref. 2) in 1971. Development of the basic model 
was completed in 1976 (Refs. 3, 4, 5, 6, 7, 8) when the model was first 
applied to a major Naval weapons system (Ref. 9). Since that time, the model 
has been applied to several other Naval systems (Refs. 10, 11, 12, 13). Each 
application has resulted in an increasing confidence in the validity and 
generality of the model and in an expansion of its range of applicability to 
more and more complex situations. 

HOS developed as a result of Wherry's work in the field of crewstation 
design, test and evaluation. He recognized that the task analyses that were 
being prepared for the Navy suffered from several major flaws. First, the 
analyses never adequately expressed what was expected of the operator. Tasks 
were specified at varying and usually macroscopic levels of detail (e.g., 
"Pilot acquires and locks on target") and the times assigned to activities 
were, at best, educated guesses. The analyses would never indicate that the 
operator was too busy to perform all the assigned functions (though in actual 
operational situations, the operator might have been) because the analyses 
were being prepared by equipment manufacturers who had vested interests in 
making their systems look good. The analyses did not realistically represent 
either the dynamics of interactions between mission functions or the inter- 
actions between the external world and operator activities. 

Wherry concluded that, since there were not standards that the Navy 
could apply to ensure an unbiased and consistent evaluation, the structure of 
a task analysis, its level of detail, and its insensitivity to variations 
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in crewstation design did not permit the realistic evaluation of design alter- 
natives. Proposed designs could still only be evaluated by building mockups, 
simulators, and prototypes and running subjects through test scenarios. But 
such studies, in addition to being costly, time-consuming and confounded by 
inter-subject variability, could only be performed so late in the design pro- 
cess that the results of the studies could have only minimal impact on the 
ultimate system design. 

Wherry proposed the development of a computer simulation model that 
would be capable of simulating an operator in a complex crewstation to the 
level of detail needed for realistic evaluation of alternative designs within 
the context of simulated missions. The model would be capable of producing 
the types of data that had been obtainable only from man-in-the-loop experi- 
mentation. The characteristics of the crewstation, the performance require- 
ments of the operator and the details of the missions that could be specified 
to the model were to be completely general. The simulation would become a 
specific operator with specific tasks to accomplish when the analyst supplied 
a description of the crewstation, the procedures the operator was to follow 
to utilize the equipment and a description of the behavior of the external 
world, just as a human being becomes the operator of a system when placed 
in a crewstation, told how to use the equipment and given a specific job to 
do. 


To facilitate the process of defining the crewstation, the operator pro- 
cedures, and the external world, an Engl ish/FORTRAN-1 ike language -- the Human 
Operator Procedures (HOPROC) language -- was developed. HOS translates HOPROC 
statements describing macro-level operator actions into micro-level activities 
whose performance times are dependent on basic human performance characteris- 
tics and the mission dynamics (Ref. 14). 

The HOS approach differs significantly from the approaches used in models 
like SAINT (Refs. 15, 16, 17, 18), Siegel-Wolf (Refs. 19, 20, 21), TLA (Refs. 
22, 23) and the various control theory models (Refs. 24, 25). The essence of 
HOS is an explicit model of the operator and of how the operator translates 
procedural statements into activities. Underlying the HOS model is the 
assumption that human performance (in general) and the performance of a well- 
trained operator (in particular) is explainable as the concatenation of micro- 
activities. The performance time for each micro-activity is predictable and 
expressed functionally by the micro-model for that micro-activity. Since the 
human performance micro-models are based on experimental data, HOS is not only 
a means of evaluating complex systems, but also a structure within which 
experimental models of human performance can be tested and evaluated. 


THE HOS OPERATOR MODELS 


There are five major micro-models in HOS -- an anatomy movement model, 
an information absorption model, a mental computation model, a decision- 
making model, and a control manipulation model. These models were developed 
from analyses of both published and unpublished data on human performance. 
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Where no data or models were found to exist, "common-sense" models were 
developed. These models can be modified either as new data becomes available 
or as specific applications indicate the need for model improvements. The 
models and the sources from which they were derived are discussed in detail 
elsewhere (Ref. 14). However, for the purposes of understanding visual per- 
formance as modeled in HOS, it is necessary to briefly review the eye move- 
ment features of the anatomy movement micro-model and the information absorp- 
tion micro-model and the HOS models of operator variability and error, 


Eye Movement 


When a HOPROC instruction (e.g., READ THE ALTIMETER) requires the 
operator to move his eyes to a specific device, the eye movement micro-model 
is accessed. This model computes a movement time based on location of the 
current eye fixation point and the new fixation point. The equations used in 
this micro-model are based on published experimental data on lateral eye 
movements (Ref. 26) and data from an unpublished experiment by Wherry and 
Bittner involving both lateral and convergence movements. Figure 1 indicates 
the range of eye movement times for situations involving only lateral move- 
ments between two fixation points on a plane 71 cm (28 in.) from the operator 


Information Absorption 


The HOS information absorption micro-model is dependent on a hab 
strength parameter, derived from Hull's learning theory habit strength con- 
cept. Information is absorbed in discrete chunks [micro-absorptions). Each 
micro-absorption increases the operator's confidence (hab strength) until the 
operator is sufficiently confident in his knowledge of the value of the de- 
vice, at which time the absorption process is terminated. 

Each micro-absorption results in the addition of a micro-absorption 
time charge whose value is dependent on input quantities supplied by the 
analyst in combination with characteristics of the device (e,g., whether the 
device is discrete or continuous, how many settings it has, etc.), Figure 2 
indicates how hab strength varies as a function of time for four different 
devices. 


Operator Performance Variability 


The HOS model views operator performance variability as the result of 
differences in the performance capabilities of different subjects coupled 
with differences in operator strategies. Differences in performance capa- 
bilities are represented by parametric differences in the functional relation 
ships in the micro-models. Differences in operator strategies are repre- 
sentable as either different decision rules in the operator procedures or 



as differing prioritizations of the operator procedures. By parametrically 
varying these quantities, HOS can be used to evaluate both the operator per- 
formance required by a system and alternative operator strategies and priori- 
tization schemes. The first type of evaluation (operator performance capa- 
bilities) can be useful in the process of screening candidate operators. The 
latter evaluation (strategies and prioritization schemes) can help to develop 
training procedures that will ensure that operators are trained to optimally 
utilize the system's capabilities. Although both of these possible uses of 
HOS have yet to be explored, they were anticipated in Wherry's original con- 
ceptualization of HOS. The former was implied by the "o-state" (operator 
state) concept that allows variations in the operator performance equations 
throughout the mission; the latter in the criticality values assigned to dif- 
ferent operator procedures that can be (and are) dynamically modified through- 
out the simulation 1 and in the English-like syntax of the HOPROC language 
that enables the HOS procedures to be used directly as training materials. 


Operator Error 


One of the most controversial issues associated with HOS is its model of 
operator error. To understand this model, it is important to remember that 
the primary objective for which HOS was developed was the evaluation of the 
nominal performance of a system by a well-trained , average operator. By 
definition, a well-trained operator is one who carries out instructions "by 
the book," without omitting a step, making an incorrect decision (based 
on the decision rules specified in the instruction set), or incorrectly 
carrying out an instruction. However, this definition does not preclude all 
sources of operator error. For HOS, the significant sources of operator 
error are: 

(1) Requiring the operator to perform more activities in a given period 
of time than possible (because of human and/or equipment limita- 
tions), thereby causing the operator to "fall behind" in the 
mission. 

(2) Giving the operator an incorrect set of decision rules and/or 
operating instructions, thereby causing tactical and/or operational 
errors . 

(3) Giving the operator poor displays and/or controls that do not per- 
mit information to be read or controlled with sufficient accuracy 
to permit proper operation of the system, causing errors to occur 
in carrying out subsequent (or concurrent) operations and/or 
requiring the operator to invest more time, once again causing the 
operator to fall behind in the mission. 

These types of errors result in operator performance errors, but are 
really failures in the design of the system — flaws which the human factors 
engineer must address in proposing design modifications. They are problems 
created when system designers fail to take into account human performance 
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limitations. Clearly, they are not errors of the same sort as when an opera- 
tor inadvertently pushes a wrong button -- such errors are either random and 
of low frequency (in which case it is unfair to use them to evaluate the 
nominal performance of the system) or caused by working the operator beyond 
capacity. They are, however, the types of errors that must be engineered 
out of the system. 


VALIDATION 


Validation of any complex model (and particularly a Monte Carlo simula- 
tion model like HOS) is fraught with difficulties. One can argue that such 
models can never be fully validated -- the best one can hope for is that in 
specific situations, given well-defined sets of inputs, the model can be shown 
to produce the outputs that match expectations, experience and available data. 
The problem is even more complex with a model like HOS because, unlike simula- 
tion systems that manipulate the user's model of a situation (i.e., the 
inputs) according to incontrovertible mathematical formulae, in HOS there is 
both the HOS model of the operator and the user's model of how the system 
functions and how the operator will utilize it. Both models must be valid 
for the results of any particular simulation to be valid. But since human 
behavior is so complex, one can never be sure that all possible circumstances 
have been fully described and all possible alternatives foreseen. It is 
therefore almost impossible to validate any specific model. 

Notwithstanding these difficulties, efforts have been made to ensure 
both the validity of the HOS operator model and the reasonableness of the out- 
puts obtained from specific user models. Tests of the validity of the HOS 
model have involved simulations of specific experiments drawn from the human 
factors and experimental psychological literature (Refs. 8, 10, 11). User 
model validations have included simulations of specific Navy crewstations 
(Refs. 9, 12, 13). Both types of simulations have confirmed the general 
validity of HOS. 

Although comparing model results with experimental data has generally 
been straightforward, validation of the model in complex military situations 
has been problematical because of the difficulties associated with attempting 
to capture all the potentially significant variables in the simulation. The 
converse of this problem is also true -- one can establish a scenario that can 
be run through HOS, but it is difficult (if not impossible) to set up real- 
world situations (e.g., at-sea exercises) that will conform to the hypothetical 
situations modeled in the simulations. Further confirmation of the HOS model 
is expected as the result of a series of HOS simulations coupled with labora- 
tory experiments that are currently in the planning stages. These simula- 
tions will attempt to ensure the validity of the model (and will determine the 
values of certain input data quantities needed by the model) for a range of 
situations of varying complexity commonly experienced in Naval weapons systems. 
In addition, an effort is currently underway with NASA Langley that will test 
a HOS pilot model through its conformance with visual performance data col- 
lected by Spady and Kurbjun (Ref. 27). Preliminary details on this model are 
presented below. 
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THE HOS/NASA LANGLEY PILOT MODEL 


An operator can be modeled as timesharing his attention among a set of 
monitoring procedures designed to keep specific displayed items of information 
at their nominal values. For example, in the approach phase of an IFR land- 
ing, a pilot timeshares his attention among at least eight different instru- 
ments simultaneously -- the ADF, the radar altimeter, the horizontal and 
vertical situation indicators, the barometric altimeter, the airspeed indica- 
tor, the clock, and the flight director. HOS enables the analyst to describe 
the pilot's monitoring behavior by a set of monitor procedures. Each instru- 
ment has its own monitor procedure, e.g.: 

DEFINE THE PROCEDURE TO MONITOR THE ALTIMETER. 

IF THE ESTIMATED VALUE OF THE ALTIMETER IS WITHIN LIMITS 
THEN WAIT. 2 


Such procedures define the actions that the operator is to perform in 
order to keep the specified instrument within a predefined (and dynamically 
modifiable) set of limits. These limits, which are defined around a desired 
value (also dynamically modifiable) can be set to a value of zero, in which 
case the pilot will act like an optimal controller by continuously taking 
actions to minimize the error. Alternatively, the limits can be set to some 
non-zero value, in which case the pilot will only take corrective action when 
the displayed item exceeds its allowable range of variability. 

Monitor procedures are executed periodically with a frequency dependent 
upon a set of decision rules that are part of the HOS decision-making micro- 
model. These rules use values of how long it has been since the procedure 
was last executed, how close the device being monitored is to its desired 
value and the criticality of the device to determine which procedure to work 
on next. Thus, if all devices are of equal criticality and at their nominal 
values, each monitor procedure would be executed once before any procedure 
was executed a second time. By assigning appropriate criticalities to the 
devices (or to the monitor procedures, themselves), the analyst can control 
the frequency with which the procedures are executed. When the value of the 
device differs from the nominal, the HOS decision-making algorithms will 
perturb the a priori criticalities (and hence the nominal monitoring fre- 
quencies) by an amount dependent on the deviation of each device from its 
nominal value. These changes in the monitoring frequencies correspond to 
the effects that one sees in a pilot's performance when certain devices 
become more critical during certain mission phases or when the pilot dedicates 
more time to maintaining control over certain items because they are harder 
to control . 

Spady and Kurbjun collected (Ref. 27) oculometer data on pilot eye 
movements during both actual and simulated approaches and landings. Their 
data functionally describes the variation in the pilot's perceived criticality 
under varying circumstances. The data on coupled (i.e., autopilot engaged) 
approaches, for example, (Figure 3), is indicative of operator monitoring 
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frequencies when the operator has a minimum number of functions to perform, 
i.e., when all devices remain within their limits and no corrective actions 
are required by the operator. 3 Their data for uncoupled (autopilot disengaged) 
approaches (Figure 4) indicates how these frequencies change when additional 
pilot control functions are added. In HOS, this corresponds to increasing 
the pilot's hab strength thresholds when the pilot is performing the control 
functions and to the addition of the control activities defined by succeeding 
statements in the monitor procedures. 

It is expected that the HOS micro-models will produce eye movement data 
directly comparable to the data obtained by Spady and Kurbjun (Figures 3 
through 5). 


SUMMARY AND IMPLEMENTATION CONSIDERATIONS 


This paper has discussed those aspects of the HOS model pertaining to 
the modeling of visual performance data and the efforts that are currently 
underway to confirm the validity of those models. 

CDR Norman Lane, Naval Air Development Center, Warminster, Pa., directs 
the Navy's HOS modeling efforts. The Navy is anxious to encourage others to 
use the model and will provide access to the model for those wishing to. 

HOS consists of three major programs which are in FORTRAN, but use some 
CDC-specific features. The programs would therefore require some (relatively 
minor) conversion before they could be used on another computer system. The 
program is large (it can use 200K 8 words or more of storage for complex 
simulations 4 ) and, for complex problems, can be expensive to run. However, it 
offers the potential for substantial savings when used as a substitute for 
real-time simulations and as a means for obtaining types of data that might be 
virtually impossible to obtain by any other means. HOS should also be con- 
sidered as an integral part of the system design process, enabling the human 
factors engineer to propose, test, and either justify or reject proposed sys- 
tem designs based upon a clear and consistent model of human performance. 
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FOOTNOTES 


Criticalities can be explicitly modified by procedural statements and are 
implicitly modified by the model's decision-making micro-model. 

2 This statement can also be written as either 

IF THE ALTIMETER IS WITHIN LIMITS THEN WAIT. 


or 


IF ALTIMETER IS OK THEN WAIT. 

or in any one of a number of other semantically equivalent forms. The HOPROC 
syntactical analyzer program translates them all into a standard form for use 
by the simulator. 

3 These data are only indicative of the monitoring frequencies because the 
Piedmont 737 1 s flown were not equipped with an auto throttle; therefore, the 
pilot was required to control the airspeed with the throttle. 

4 A version of HOS that uses the CDC Extended Core Storage facility is also 
available. 
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213m (700 ft) to 3m (100 ft) altitude 
above ground level 



Time from start of run, sec 

Figure 3.- Time history of one pilot's scan during coupled approach. 

213m (700 ft) to 30m (100 ft) altitude 


above ground level 



Time from start of run, sec 


Figure 4.- Time histories of one pilot's scan during manual approach. 
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